Cobra Utilities for Doom & Doom II

home *** CD-ROM | disk | FTP | other *** search

/ Cobra Utilities for Doom & Doom II / Cobra Utilities For Doom & Doom II - Disc 2.iso / files / text / dmltyp / lintyp10.txt

Wrap

Text File | 1994-05-20 | 16.4 KB | 410 lines

LINE TYPES ************ This file is written by Brian McKimens (samneric@connected.com) dmspec13 is written by Matt Fell (matt.burnett@acebbs.com) and distributed by Hank Leukart (ap641@cleveland.freenet.edu) DEU 5.1 is written by Raphael Quinet (quinet@montefiore.ulg.ac.be) and Brendon J. Wyber (b.wyber@csc.canterbury.ac.nz) Following is a list of LINE TYPES available for wad editing. I hope this information will allow you to better design levels. I gathered this information from dmspec13 and from experiments with DEU 5.1 to determine the actual effects of the line types. I found numerous errors in the descriptions in DEU 5.1 and many omissions in the descriptions in dmspec13. I just started to figure out what 1 particular type did. In the course of experimenting, I was able to determine what other line types actually do and to fill-in a large part of the missing descriptions. Newly discovered line types are preceeded by an asterisk (*). I don't pretend that this is error-free, but in as many cases as possible, I tested those line types that I DID test under as many different conditions as needed to feel secure in the description. If you find errors, please e-mail me and be sure to include a GOOD description of the discrepency (hopefully, a zipped, binary wad containing NO MORE THAN NECESSARY to run and illustrate the condition!). There are still line types not defined, and they are listed at the end of this file. There are also sector types (2) not defined yet and some of these line types may behave differently when tagged to those type of sectors. Who knows?... A bottle of Murine to whoever figures out what these undefined sector and line types do! DEU 5.1 allows use of these new and corrected types to be inserted manually by entering a decimal number for the line type by hand. It allows you to insert a number up to 255, but the known line types at this time only range from 0-104. Dmspec13 refers to a line type of -1 that occurs in E2M7 in one room. Since this doesn't "appear" to have a function in the room that uses it (on every major wall, I might add), I'm gonna consider it a bug for ID to squash when they get around to it. Like that Sargeant stuck between walls, and the Spectre stuck TO a wall, in E1M6. At least until someone come up with a purpose for it. LINE TYPE is a term that refers to an effect that can be triggered by an ACTION on the related linedef. The word "function" might better describe TYPE than "type" does. The DOOM engine calls certains functions when the linedefs are activated by shooting, crossing, or butting up next to them and hitting the spacebar. ID isn't likely to release their source code, but we can experiment and discover "what happens" when we set a linedef to a certain TYPE and then activate it. This is what dmspec13 contains - results of experiments performed on wads to see what happens. This file is just a continuation of the efforts of other people to unravel the "secrets" that the mighty DOOM engine hides... I use some terms in this file that I have not seen used before to describe the line types or the sectors that they affect, so I will define them as I go. The first two that I'll introduce refer to the relationship of two sectors that share one or more linedefs. Such sectors are ADJACENT. All sectors are also adjacent to themselves, as they share linedefs (sidedefs even!) with themselves. Sectors A & B below are adjacent, as are C & D, E & F. Sector E can also be said to CONTAIN sector F. Sector F shares all of it's lindefs, but with only one sector (E). CONTAIN is a term that figures into the operation of line type #9 (a floor-affecting line type). ___________ ___________ ___________ | | | | | | | | | D | | ___ E | ____| B | |____ | | | F | | | A | | | C | | | |___| | |____|___________| |____|______| |___________| In describing the floor effects, dmspec13 used the term "neighbor" ("ne."). This term was also echoed by the authors of the various editors. The problem with this term is that it implies that a neighbor to sector #X can not be sector #X itself. When the DOOM engine looks for the Lowest Adjacent Ceiling to raise a floor up to, it may find that the LAC is the ceiling belonging to the same sector as the rising floor. If it stops 8 below the LAC in this instance, it will be 8 below it's own ceiling. If we can adopt these or similar terms, then describing effects of certain linetypes will be easier. ---------------- Following are the terms used in the descriptions of line types: DEC# **** Decimal number of the line type. ACT. **** Activated by. This indicates what will activate the effect. S 1 - Switch activated. Not repeatable. S R - Switch - repeatable after sector is reset. S X - Switch - repeatable without requiring sector reset. (use of this linetype is not recommended) W 1 - Walking across line activates. Not repeatable. W R - Walking - repeatable after sector reset. W X - Walking - repeatable without requiring resetting. (use of this linetype is not recommended) G 1 - Gun activated. (Shoot at or through line to activate) EFFECT ****** What happens to the involved sector when triggered by the linedef. EFFECT Terms: HAC - Highest Adjacent Ceiling LAC - Lowest Adjacent Ceiling HAF _ Highest Adjacent Floor LAF - Lowest Adjacent Floor NAF - Numeric Adjacent Floor. This is the floor of the adjacent sector that shares the lowest numbered linedef of the tagged sector. NUMERIC CHANGE - defined before the section on floors TRIGGER CHANGE - defined before the section on floors DEC# ACT. EFFECT **** **** ****** 0 - - Normal (used to indicate no special handling of linedef) ----------- DOORS These are actually ceiling effects, as doors are just ceilings that are raised and lowered to allow access to the sectors lying beyond them. I'm grouping them separately since designers put "doors" in wads, not "ceilings with specific behaviors". LOCAL DOORS - sectors bound to 2nd sidedef of activating linedef. (activated at door surface) DEC# ACT. EFFECT **** **** ****** 1 S R Open door. Closes in 6 secs 26 S R Open door. Closes in 6 secs. Blue key 27 S R Open door. Closes in 6 secs. Yellow key 28 S R Open door. Closes in 6 secs. Red key 31 S 1 Open door. Stays open 46 G 1 Open door. Stays open 32 S 1 Open door. Stays open Blue key 33 S 1 Open door. Stays open Yellow key 34 S 1 Open door. Stays open Red key REMOTE DOORS - sectors tagged by activating linedef. (remotely activated at wall switches, walk-over lines) (* indicates not in dmspec13 and unavailable in editor menus at this time.) DEC# ACT. EFFECT **** **** ****** 103 S 1 Open door. Stays open 61 S R Open door. Stays open 2 W 1 Open door. Stays open 86 W R Open door. Stays open 29 S 1 Open door. Closes in 6 seconds 63 S R Open door. Closes in 6 seconds * 4 W 1 Open door Closes in 6 seconds 90 W R Open door. Closes in 6 seconds * 50 S 1 Close door 42 S R Close door 3 W 1 Close door 75 W R Close door 16 W 1 Close door for 30 seconds 76 W R Close door for 30 seconds ---------------------- CEILINGS DEC# ACT. EFFECT **** **** ****** 40 W 1 Raise to HAC 41 S 1 Lower to own floor * 43 S R Lower to own floor * 49 S 1 Lower to 8 above own floor. 44 W 1 Lower to 8 above own floor * 72 W R Lower to 8 above own floor * 25 W 1 Start fast crushing ceiling. Fast crush. Slow damage * 6 W 1 Start fast crushing ceiling. Fast crush. Fast damage 77 W R Start fast crushing ceiling. Fast crush. Slow damage 73 W R Start slow crushing ceiling. Slow crush. Fast damage * 57 W 1 Stop crushing ceiling 74 W R Stop crushing ceiling ------------------ FLOORS Floor-affecting types trigger effects best described as RAISE, LOWER, GOTO. There are also types affecting MOVING FLOORS, LIFTS, and STAIRS, but I'm treating these as separate cases since most designers view these as complete entities - much the same as doors are considered separate from ceilings, even though door actions are actually ceiling actions. RAISE types will move the floor up, either until a given numerical distance has been traveled, or until it reaches a position relative to an adjacent floor or ceiling. RAISE types should not be used if the relative position is, or can be relocated to, BELOW the floor before triggering. LOWER types will move the floor only to positions relative to an adjacent floor or ceiling. LOWER types should not be used if the relative position is, or can be relocated to, ABOVE the floor before triggering. The GOTO type is a term not used before. GOTO raises OR lowers the floor to a given height or location. Many of the earlier descriptions referred to RAISE or LOWER types only, because the floors that were studied to find the resulting actions were set below or above the GOTO destination already. GOTO types are useful when multiple sectors are tagged together, each having a different height. Each will move in whatever direction is required to end up at the same height. SPECIAL NOTE ************ Some floor types also cause the tagged sector to change floor texture and "damage" trait to that of a 2nd sector (MODEL sector, for lack of a better term). There are 2 different models involved in the changes. A TRIGGER model is the sector that is bound to the first sidedef of the triggering linedef. A NUMERIC model is the adjacent sector sharing the LOWEST NUMBERED LINEDEF comprising the tagged sector. These are referred to in the EFFECTS column below as either TRIGGER CHANGE or NUMERIC CHANGE. In either case, the tagged sector takes on the floor texture of the model sector. In the case of the NUMERIC CHANGE a second trait is also passed to the tagged sector - the ability to do health damage. This was previously considered to be a passing of the SECTOR TYPE from the model to the tagged sector, but that is not the case. The sector type also describes light characteristics, but these are not passed to the tagged sector. A TRIGGER CHANGE also appears to "lock-out" any further changes to a sector by any linedef tagged to it. I refer to the floor of a Numeric model as an NAF - Numeric Adjacent Floor. Dmspec13 referred to the change as "matching", but it also used that term to describe a RAISE or LOWER destination height. I will try to avoid the term, as its meaning has already been muddied. One notable line type involving floors: Line type #9 is recognizable as the switch to activate the chainsaw pillar in E1M2. The tagged sector (pillar) moves in GOTO mode to its NAF (Numeric Adjacent Floor) comprised of the acid pool surrounding it. (If the acid pool is the tagged sector and the pillar shares its lowest numbered linedef, the pool will GOTO the level of the pillar. You can turn off clipping and climb up to it and still be harmed by the acid.) But in this case, the pillar is tagged, so it moves to the floor level of the acid pool sector. Note that the pillar is CONTAINED by its NAF sector, as all of its linedefs are shared by the acid pool. Because of this, a second condition sets in - the acid pool "GOesTO" >its< NAF and undergoes a NUMERIC CHANGE, assuming the same floor texture and damage trait (no longer damaging to health). The acid pool is contained by its own NAF in this case, but that is not required for the second step to occur. The pool would move to its NAF even if stuck in a corner, as long as the lowest numbered linedef bounding the acid pool is a TWO-SIDED LINEDEF. The primary NAF sector (the acid pool) does NOT consider the tagged sector (the pillar) to contain its NAF. It looks elsewhere, EVEN IF its lowest numbered linedef is shared with the tagged sector. The acid pool finds its NAF among its other shared linedefs. There is a bug I found. If the acid pool's lowest numbered linedef is a ONE-SIDED linedef, the pillar and acid pool floors both GOTO a height of 34, and the acid pool turns from NUKAGEn to TLITE6_6 - the last one on the list. (Probably from a function returning a pointer to it after being passed junk.) Since ID doesn't make this mistake, you would do well to emulate them. One last note on this line type - If the tagged sector's lowest numbered linedef is ONE-SIDED, it is considered to have no NAF, and nothing happens. FLOORS DEC# ACT. EFFECT **** **** ****** 18 S 1 Raise to next-higher floor * 69 S X Raise to next-higher floor 5 W 1 Raise to next-higher floor 20 S 1 Raise to next-higher floor TRIGGER CHANGE * 68 S 1 Raise to next-higher floor TRIGGER CHANGE 22 W 1 Raise to next-higher floor TRIGGER CHANGE * 95 W 1 Raise to next-higher floor TRIGGER CHANGE * 47 G 1 Raise to next-higher floor TRIGGER CHANGE * 101 S 1 Raise to LAC * 64 S R Raise to LAC * 24 G 1 Raise to LAC * 55 S 1 Raise to 8 below LAC CRUSH * 65 S R Raise to 8 below LAC CRUSH * 94 W 1 Raise to 8 below LAC CRUSH 56 W 1 Raise to 8 below LAC CRUSH 58 W 1 Raise 24 * 92 W X Raise 24 * 15 S 1 Raise 24 TRIGGER CHANGE * 66 S X Raise 24 TRIGGER CHANGE 59 W 1 Raise 24 TRIGGER CHANGE * 93 W X Raise 24 TRIGGER CHANGE 14 S 1 Raise 32 TRIGGER CHANGE * 67 S X Raise 32 TRIGGER CHANGE 30 W 1 Raise 128 * 96 W X Raise 128 23 S 1 Lower to LAF * 60 S R Lower to LAF 38 W 1 Lower to LAF 82 W R Lower to LAF 37 W 1 Lower to LAF NUMERIC CHANGE * 84 W R Lower to LAF NUMERIC CHANGE 91 W R Goto LAC 102 S 1 Goto HAF * 45 S R Goto HAF 19 W 1 Goto HAF * 83 W R Goto HAF * 71 S 1 Goto 8 above HAF 70 S R Goto 8 above HAF 36 W 1 Goto 8 above HAF 98 W R Goto 8 above HAF This next one is a bit involved. Explained further above. Example: switch activating pillar with chainsaw in E1M2. 9 S 1 { Goto NAF1; IF (contained by NAF1) { NAF1 Goto its own NAF2 and undergo NUMERIC CHANGE; } } FLOORS USED AS LIFTS DEC# ACT. EFFECT **** **** ****** 21 S 1 Lower quickly for 3 seconds, then return 62 S R Lower quickly for 3 seconds, then return 10 W 1 Lower quickly for 3 seconds, then return 88 W R Lower quickly for 3 seconds, then return MOVING FLOORS DEC# ACT. EFFECT **** **** ****** * 53 W 1 Start moving floor 87 W R Start moving floor * 54 W 1 Stop moving floor 89 W R Stop moving floor ------------------------------------------ From here on down, with the exception of those types marked with an asterisk (*) and those as yet undefined, I didn't experiment with these line types. Most of the descriptions are unchanged from how they appear in dmspec13. STAIRS DEC# ACT. EFFECT **** **** ****** 7 S 1 Staircase rises up from floor in appropriate sectors. 8 W 1 Stairs END LEVEL DEC# ACT. EFFECT **** **** ****** 11 S - End level. Go to next level. 51 S - End level. Go to secret level 9. 52 W - End level. Go to next level TELEPORT DEC# ACT. EFFECT **** **** ****** 39 W 1 Teleport to sector. (Only ONE sector per tag #) 97 W R Teleport to sector. (Only ONE sector per tag #) LIGHT LEVELS DEC# ACT. EFFECT **** **** ****** 13 W 1 Brightness goes to 255 * 17 W 1 Change light to blink - 1 sec. 104 W 1 Light drops to lowest light level amongst neighbor sectors 35 W 1 Light drops to 0. * 79 W R Light drops to 0. 80 W R Brightness to maximum neighbor light level MISCELLANEOUS DEC# ACT. EFFECT **** **** ****** 48 - - Animated, horizontally scrolling wall texture (right to left) (This is an non-triggered condition affecting only how the wall texture is painted onto the sidedef.) STILL UNKNOWN AT THIS TIME 12 - affects light level 78 81 83 84 85 99 100